The present invention relates to storage systems and more particularly to systems and methods for pre-selecting disks based on the disks"" validity with respect to volumes within a networked storage system environment.
A file server is a type of storage system, that provides file service relating to the organization of information on storage devices, such as disks. The file server or filer implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each xe2x80x9con-diskxe2x80x9d file may be implemented as a set of disk blocks configured to store information, such as text, whereas the directory may be implemented as a specially formatted file in which information about other files and directories are stored.
A storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a file system protocol, executing on a computer that xe2x80x9cconnectsxe2x80x9d to the filer over a computer network, such as a point-to-point link or a shared local area network (LAN) or wide area network (WAN). Each client may request the services of the filer by issuing file system protocol messages (in the form of packets) to the filer over the network.
A filer is organized so that it includes one or more storage xe2x80x9cvolumesxe2x80x9d that comprise a cluster of physical storage disks, defining an overall logical arrangement of storage space. Currently available filer implementations can serve a large number of discrete volumes (for example 150, although this number is subject to increase). Each volume is generally associated with its own file system. The disks within a volume/file system are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). RAID implementations enhance the reliability and integrity of data storage through the redundant writing of data xe2x80x9cstripesxe2x80x9d across a given number of physical disks in the RAID group, and the appropriate caching of parity information with respect to the striped data. In the example of a WAFL-based file system, a RAID 4 implementation is advantageously employed. This implementation specifically entails the striping of data across a group of disks, and separate parity caching within a selected disk of the RAID group. Thus, in such a RAID 4 implementation, a volume includes at least two disks, namely, at least one data disk and one associated parity disk.
From time to time during operation, a storage system will need to create a new volume or extend an existing volume by adding disk drives as storage needs change. Moreover, one or more of the physical disk drives that comprise a volume may fail, in which case, the malfunctioning disk will need to be removed from the RAID group and/or volume and replaced with a working one. Many storage systems have a xe2x80x9cpoolxe2x80x9d of spare disks that are attached to the system but have not been assigned to a file system or volume, and consequently are not actively storing data (i.e., such disks are not active disks). These spare disks can be utilized to form or extend volumes or replace a malfunctioning disk.
A spare disk that is to be used in creating a volume or to be added to an existing volume should have certain characteristics. These can include xe2x80x9cdisk characteristicsxe2x80x9d and xe2x80x9cvolume characteristics.xe2x80x9d An example of a disk characteristic is the size. For example, if a disk that is being replaced is 9 gigabytes (GB), the replacement disk should be at least 9 GB in size. An example of a volume characteristic is the style of checksum. Two common types of checksum are block and zoned. Block checksum sectors contain a 512-byte data segment and an eight-byte checksum for a total of 520 bytes per sector (BPS). Zoned checksum sectors contain a data segment and checksum, with a total of 512 BPS. A disk formatted with a 512 BPS configuration generally cannot be used in a block checksum volume; however, a disk formatted with a 520 BPS configuration can be used in either a block checksum volume or a zoned checksum volume. If a 520 BPS disk is used in a zoned checksum, the extra eight bytes are not used. For example, if a disk from the spare pool is to be added to a volume using blocked checksum, the spare disk must have 520 BPS. A spare disk having only 512 BPS could only be validly assigned to a volume using zoned checksum.
A user may interact with a filer to create a volume or to add a disk to an existing volume through the use of a command line interface (CLI) or a graphical user interface (GUI). The CLI enables the user to type in commands for the filer to execute. The GUI is typically accessed via a web browser running on the user""s computer and connected to the filer via a hypertext transfer protocol (HTTP) connection. The GUI presents a menu of options that is selected by the user via a mouse or other pointing device and generates commands for the filer to execute.
In a known system employing a manual approach to disk selection, a GUI option, screen is used to display user-selectable operations, for example the option to create a volume or to add a disk to a volume. The option screen may also show, a list of identifiers (Ids) of available disks in the spare pool and their size. The user can select one or more disks from the screen (e.g., by highlighting the selected disks in the list) in accordance with the requested xe2x80x9ccreatexe2x80x9d or xe2x80x9caddxe2x80x9d operation. The user makes the selection in this known system based on what the user knew of any required disk and volume characteristics since no such information is normally displayed on screen. Since the list of spares includes all disks (even those not xe2x80x9cvalidxe2x80x9d for the requested operation, e.g., due to their size or checksum), the user might select an invalid disk. If the user selects a disk that is not valid and then attempts to initiate the resulting command, (by submitting the page to the filer via HTTP for processing by the storage operating system), an error message is generated and the command is not executed. Thus, the administrator or user must go through a trial and error process to be able to successfully add a disk to a volume. While suitable for the more sophisticated users, this manual approach manifests distinct disadvantages in ease of operation.
The known system provides an alternative to the manual disk selection technique just described. In this alternative, the system responds to a user-indicated xe2x80x9caddxe2x80x9d or xe2x80x9ccreatexe2x80x9d operation by selecting suitable disks automatically.
Accordingly, it is an object of the present invention to provide a system and method for selecting disks for creation or expansion of a volume that provides ease of use and faster administration, while giving the user a high degree of control in the disk selection process.
This invention overcomes the disadvantages of the prior art by providing a system and method for pre-selecting candidate disks that can be validly used with a volume of a storage system. Pre-selection can be made based on many characteristics including characteristics associated with the volume and/or the disk. The storage system creates and maintains a set of data structures or tables, including a disk table and a volume table. The disk table contains characteristics of all disks affiliated with the storage system whereas the volume table contains the characteristics of all volumes served by the storage system.
The preselected disks can be presented to a user as pre-qualified candidates, from which the user can select the disks to be used in a new volume or added to an existing volume. For example, the storage system can display a graphical user interface (GUI) including an interactive screen view for volume creation and expansion, or separate screen views for the two operations. By means of the GUI, the user can be presented with a list of disks that are preselected as suitable for use with a volume. Then, the user can interactively designate (e.g., by highlighting) one or more of the disks identified in the list to be used with the volume. In alternative implementation, the user may be presented with one or more alternative mechanisms for disk designation: an automatic designation mechanism in which the system permits the user only to select the number of disks and their sizes, and a manual designation mechanism in which the system preselects the disks and permits the user to designate disks from the preselected list according to the user""s own criteria. The latter manual designation will appeal to sophisticated users who wish to custom configure the disk subsystem for performance or other reasons.
In a specific implementation, a registry is provided that interfaces with the file system and a Java virtual machine (JVM). The registry provides hooks into the volume and disk tables that are then accessible via an application program interface (API) to the JVM. A Java program, such as a servlet, can access the data stored in the tables via calls to the API. According to this implementation when a graphical user interface presents a list of disks to be selected for an xe2x80x9caddxe2x80x9d or xe2x80x9ccreatexe2x80x9d operation, only those disks that are valid for the operation are displayed. A process (e.g. a Java servlet) obtains information on the spare disks and the volume via a call to the API associated with the registry and the process selects those disks that match the characteristics required. The graphical user interface only displays valid disks for the volume involved. This pre-selection reduces operator time and errors.